Reference: #266

This PR forms part of the changes outlined in #266, specifically it includes state checks for the following:

• ExpectKnownValue
• ExpectKnownOutputValue
• ExpectKnownOutputValueAtPath
• ExpectSensitiveValue

The implementation in this PR differs from the way in which checks for known type and value are currently being handled for plan checks, in that the ExpectKnown<Value|OutputValue|OutputValueAtPath> state checks allow for explicitly checking for a null value by using a newly introduced null known value check type. An alternative can be seen in the plan check implementations, where the ExpectKnown<Value|OutputValue|OutputValueAtPath> plan checks return an error if a null value is found, and instead there are explicit checks for null values (e.g., ExpectNullOutputValue).

In this context, a significant difference between tfjson.Plan and tfjson.State is the handling of null output values. In the case of tfjson.Plan, an output that specifies an attribute, for instance, which is null appears in the plan, whereas null output values do not appear instate (refer to Allow null value outputs to be present in json output). As a consequence, there is no way for state checks that leverage tfjson.State to discriminate between output values that are null, and output values that do not exist. However, it is worth noting that output values that reference, for instance, an object that has attributes which are null will appear in tfjson.State.

Together this raises the question of whether we want to:

• Modify plan checks for ExpectKnown<Value|OutputValue|OutputValueAtPath> to handle detection of nulls (to bring them into line with the state checks for ExpectKnown<Value|OutputValue|OutputValueAtPath> in this PR).
• Modify state checks for ExpectKnown<Value|OutputValue|OutputValueAtPath> in this PR to align their behaviour with the analogous plan checks (i.e., return an error when null is detected).
• Depending upon how the known value checks are handled, decide whether we want to remove expect null value plan checks, or add expect null value state checks.

Further Considerations

• The implementation in this PR runs state checks after "post-apply, post-refresh. Do we want to consider running state checks at any other points? I avoided adding state checks for the "refresh" mode as the refresh command is deprecated, but we could consider this if it is thought to valuable. Should we consider state checks for import?
• We could also consider adding the equivalent state checks for ExpectEmptyPlan and ExpectNonEmptyPlan if there is possible value in having these built-in checks made available.